Often it is desirable for remote devices, such as wireless phones and other wireless devices (“remote devices”) to initiate or be initiated to effect an active data session with a central station, server or other uplink means. Ensuring the rapid transmission and receipt of data across a communications network, similarly, is also desirable. In these environments, however, establishing a rapid and secure path through the use of a secure protocol for providing for the secure transmission and receipt of such information is also highly desired.
It is generally known that Authentication, Authorization, and Accounting (AAA) frameworks are used in computer and cellular networks. The AAA framework is generally utilized to perform three functions: 1) to authenticate users or devices; 2) to authorize the use of resources by users or devices; and 3) to generate and store accounting information of how the users or the devices utilize the resources. Examples of two protocols that utilize the AAA framework are Remote Authentication Dial-In User Service (RADIUS) and Diameter. Details of the Radius protocol may be generally referenced at RFC 2865 (such as at http://www.ietf.org/rfc/rfc2865.txt) and details of the Diameter protocol may be generally referenced at RFC 3588 (such as at http://tools.ietf.org/html/rfc3588) each of which is incorporated herein by reference.
In a AAA framework, such as one that utilizes RADIUS or Diameter, the clients and servers (i.e., users/devices and servers) are required to be identified as between one another often by their network addresses. Once identified by one another, communications as between the client and server may be initiated based on the network addresses. Those communications become secure when communication over the protocol, as between the client(s) and server(s), is preferred through the use of shared secrets that may include a variety of forms (i.e., encrypting user names and passwords, challenge-response authentication, and/or public/private key encryption of protocol messages, for instance but not by way of limitation). Devices are identified by unique device identifiers, such as International Mobile Subscriber Identity (IMSI), Mobile Equipment Identifier (MEID), Mobile Directory Number (MDN), Mobile Station ISDN (MSISDN), and the like.
Within the AAA framework it is widely understood that the authentication, authorization and accounting information is typically exchanged as between AAA clients and AAA servers through messages transported over wired or wireless networks. Other servers also use the RADIUS and Diameter protocols for a subset of the AAA framework messages. For example, the Home Subscriber Server (HSS) uses the Diameter protocol to authenticate devices in 4G wireless cellular networks and incorporates a subset of the AAA functionality that is also covered by this invention, and the HSS is thus a AAA server for this purpose. The AAA servers are responsible for receiving user or device connection requests, authenticating the user or the device, and then returning appropriate information necessary for the client to deliver service to the user or the device. In operation, the RADIUS and Diameter protocols authorization provides that users are authorized by definition only after they pass an authentication approval from the RADIUS and Diameter server. FIG. 1 sets forth an example of the establishment of an AAA communication connection.
In FIG. 1, a host device 102 is set forth which passes a username and password 103 to the AAA client 104. Once received at the AAA Client 104, an Access-Request is transmitted at 105 to the AAA Server 106. The AAA Server 106 verifies the credentials and passes an Access Accept response at 107 to the AAA Client 104. With these responses, the Host Device 102 is able to have subscriber access of resources in a secure environment across the communications link at 110. An Accounting Request Start is transmitted at 108 to the AAA Server 106. The AAA Server 106 returns an Accounting Response at 109 to the AAA Client 104. Once the AAA Client 104 provides a stop accounting requests at 111 to the AAA Server 106, the AAA Server 106 returns an Accounting Response to stop 112 to the AAA Client 104 and the Access Termination notification is provided at 115 to the Host Device 102, terminating the communication link.
In FIG. 1, the user authentication process of a RADIUS server often involves a device that can provide a proxy function, as well. The information that is shared as between the RADIUS client and the RADIUS Server is authenticated through a shared key for security. The RADIUS protocol combines the authentication and authorization processes by sending authorization information in the authentication response message. FIG. 2 sets forth an example of the establishment of a secure communication connection over a RADIUS protocol.
In FIG. 2 a username and password 203 are entered from the user device 202 for receipt at the RADIUS Client 204. Once received at the RADIUS Client 204, an authentication request via an Access-Request is transmitted at 205 to the RADIUS Server 206. The RADIUS Server 206 compares the received user information with that in the Users database (not pictured) and then verifies the authenticity of the received data, thereafter, if favorable, passing an authentication successful message via an Access Accept response containing the information of the user's right at 207 to the RADIUS Client 204. The RADIUS client 204 similarly accepts or rejects the user according to the returned authentication result. With an Access-Accept 207, the user (i.e., subscriber) 202 is able to access the network resources as the availability of subscriber access in a secure environment across the communications link at 210. An Accounting Request (i.e. start as the value of the Status Type is “start”) is transmitted at 208 to the RADIUS Server 206. The RADIUS Server 206 returns an Accounting Response (i.e., start accounting) at 209 to the RADIUS Client 204. Once the RADIUS Client 204 provides a stop accounting requests (i.e., Status Type is “stop”) at 211 to the RADIUS Server 206, the RADIUS Server 206 returns an Accounting Response to stop 212 to the RADIUS Client 204 and the Access Termination notification is provided at 215 to the user 202, terminating the ability for the user to access the network resource.
The AAA framework provides an effective and reliable communication link when the client and server are secured, however, the AAA framework is thought to be generally limited only to that specific information and configuration data associated with the RADIUS and Diameter protocols. For instance, information that is transmitted within the AAA framework is well-defined by the fields that are defined by the various RADIUS and Diameter protocols. By way of further example, it is known that for the RADIUS protocol, the attribute fields are defined as below in Table 1.
TABLE 1Table 2 RADIUS attributesTypeAttribute type 1User-Name 2User-Password 3CHAP-Password 4NAS-IP-Address 5NAS-Port 6Service-Type 7Framed-Protocol 8Framed-IP-Address 9Framed-IP-Netmask10Framed-Routing11Filter-ID12Framed-MTU13Framed-Compression14Login-IP-Host15Login-Service16Login-TCP-Port17(unassigned)18Reply_Message19Callback-Number20Callback-ID21(unassigned)22Framed-Route23Framed-IPX-Network24State25Class26Vendor-Specific27Session-Timeout28Idle-Timeout29Termination-Action30Called-Station-Id31Calling-Station-Id32NAS-Identifier33Proxy-State34Login-LAT-Service35Login-LAT-Node36Login-LAT-Group37Framed-AppleTalk-Link38Framed-AppleTalk-Network39Framed-AppleTalk-Zone40-59(reserved for accounting)60CHAP-Challenge61NAS-Port-Type62Port-Limit63Login-LAT-Port
From Table 1, the Attribute Type carries information about the details of a request or response, by design and in accordance with the RADIUS protocol design. The Attribute Field is represented in triplets of Type, Length and Value. Similarly, an extension attribute (i.e., Attribute 26) is available to define extended attributes to implement functions that the standard RADIUS protocol does not provide.
For Type, there is one byte, in the range 1 to 255 and is used for indicating the type of the attribute. For instance, commonly used attributes for RADIUS authentication and authorization are listed in Table 1. For Length, there is one byte for indicating the length of the attribute in bytes, including the Type, Length, and Value fields. For Value, there is the value of the attribute, up to 253 bytes, typically, where the format and content depend on the Type and Length fields. While these byte lengths are prescriptive from the protocol, the actual values may vary to be less than the prescriptive values in actual operation.
As the AAA framework (inclusive of RADIUS and Diameter) provides for the ability to securely, effectively and reliably communicate across wired and wireless communication links using information in Attribute Types under the protocol, it is generally acknowledged that such communication is strictly limited only to that specific type of information and configuration data associated with the protocol and the associated Attribute Types. For instance, information that is transmitted within the RADIUS and Diameter protocols are well-defined by the designated attribute field for that information. By example, in the RADIUS protocol, a username is intended to be that content for the username, even though the attribute type for username is a Type 1 and has a Length value longer than the typical username. It is however desirous to develop a solution to benefit from the additional unused capability of the attribute types of a protocol such as RADIUS, in a communication network, thereby providing for secure, authenticated and authorized communication as between the user and the server, such that non-traditional, non-specific application data may be utilized with the Attribute Type(s) as a message including special data not otherwise originally expected or intended under the specific protocol. Preferably, it would be desired to have such a solution where the protocol reflects the principles of an authentication, authorization and accounting protocol type.
As used herein the terms device, apparatus, user, system, etc. are intended to be inclusive, interchangeable, and/or synonymous with one another and other similar arrangements and equipment for purposes of the present invention though one will recognize that functionally each may have unique characteristics, functions and/or operations which may be specific to its individual capabilities and/or deployment.